IIIllNlllllIllllllllll 

(1D EP 1 189 405 A1 



(12) EUROPEAN PATENT APPLICATION 

(43) Date of publication: (51) Int CI. 7 : H04L 29/06 

20.03.2002 Bulletin 2002/12 

(21) Application number: 00402528.4 



(22) Date of filing: 13.09.2000 



(84) Designated Contracting States: 


• Garrec, David 


AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


75015 Paris (FR) 


MC NL PT SE 


• Harroch, Erwan 


Designated Extension States: 


75014 Paris (FR) 


AL LT LV MK RO SI 






(74) Representative: Litchfield, Laura Marie et al 


(71) Applicant: MOTOROLA, INC. 


Motorola European Intellectual Property 


Schaumburg, IL 60196 (US) 


Operations, 




Midpoint - Alencon Link 


(72) Inventors: 


Basingstoke, Hampshire RG21 7PL (GB) 


• Martinez, Georges 




75013 Paris (FR) 





(54) Network system, method for transfer of data and server for use therein 




Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



(57) A network system (1 00), method and an access 
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in the wireless network to comtrol transfer of data be- 
tween the data server and the terminal in dependence 
on the held information, so as to optimize resource use 
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Description 

Field of the Invention 

[0001] This invention relates to network systems, and 
particularly those composed of wired (e.g., Internet) and 
wireless networks (e.g., DVB-T, UMTS). 

Background of the Invention 

[0002] In the field of this invention, such systems may 
have servers located in the fixed network, and multi- 
mode terminals for user access. When multiple hetero- 
geneous networks are available to terminals due to the 
increasing opportunities of wireless access to services 
and content, users request ubiquitous access, regard- 
less of terminal capabilities, radio technology coverage 
and user behaviour. 

[0003] In such a context, a user may face one or more 
of the following situations: 

• there may be no appropriate available Quality of 
Service (QoS) characteristics (e.g., latency, band- 
width, jitter, etc.) suited for a required application; 
there may be no appropriate delivered content for 
the specific user situation (e.g., delivery of content 
to a user may be constrained by user's bandwidth 
availability, location, display, etc.); and 

there may be no service continuity with user mobility 
(e.g., with change in user's network, or change in 
user's terminal). 

[0004] The user's terminal is in a radio environment 
in which it has to use one radio technology among sev- 
eral. The terminal will select the most appropriate radio 
technology according to criteria such as signal strength, 
required/desired QoS, cost for the terminal, etc. 
[0005] However, the radio technology choice made by 
the terminal may not be optimal, for example: 

• for the radio and fixed networks, because they can 
be or become congested due to user selection; and 

• for the server, because it must tailor the data (con- 
tent, quality, etc.) according to the radio technology 
being used. 

[0006] Furthermore, in most cases the server will not 
be enabled for managing user mobility among multiple 
radio technologies if the terminal is multimode. 
[0007] The terminal middleware can be modified in 
such a way that it constantly monitors the available radio 
technologies and selects the most appropriate one with- 
out connection drop. Although this approach provides 
service continuity over multiple radio technologies, it is 
user centric, and does not allow the network to deter- 
mine if other choices would be most appropriate. Fur- 
thermore, the application may experience strong trans- 
port QoS variations leading anyway to service discon- 



2 

nection. 

[0008] Servers can be upgraded with additional fea- 
tures such as format translation, requiring from applica- 
tion provider to constantly improve the services provid- 
5 ed by the server, rather than the content. However, in 
the case of multicast to users with different capabilities, 
the server would have to specifically tailor the contents 
for each user. 

[0009] In most cases, there is no correspondence be- 
tween the user-specific situation (mobility, user-specific 
behaviour, etc.) and the content presentation. As a re- 
sult, radio and network resources may be non-optimally 
used. Furthermore, there is no point in the network 
where the terminal choices and allocations are gath- 
ered, in such a way that system wide optimizations could 
be performed. 

[0010] It is an object of the present invention to pro- 
vide a network system, method for transfer of data and 
server for use therein wherein the abovementioned dis- 
advantage^) may be alleviated. 

Statement of Invention 

[0011] In accordance with a first aspect of the present 
invention there is provided a network system, including 
a wired network and a wireless network, as claimed in 
claim 1. 

[0012] In accordance with a second aspect of the 
present invention there is provided access server, for 
use in a network system including a wired network and 
a wireless network, as claimed in claim 3. 
[001 3] In accordance with a third aspect of the present 
invention there is provided method, for transfer of data 
between a data server and a terminal across a wired 
network and a wireless network, as claimed in claim 5. 

Brief Description of the Drawing(s) 

[0014] One system and method for joint operation of 
heterogeneous networks and resource use optimisation 
in a composite radio environment incorporating the 
present invention will now be described, by way of ex- 
ample only, with reference to the accompanying drawing 
(s), in which: 

FIG. 1 shows a schematic diagram of a composite 
radio system utilizing the present invention; 

FIG. 2 shows a schematic diagram illustrating or- 
ganisation of the composite radio system of FIG. 1 , 
with multiple composite access servers (CASs); 

FIG. 3 shows a schematic diagram illustrating ad- 
dressing principles used in the system of FIG. 1; 

FIG. 4 shows a block-schematic diagram illustrating 
call modelling principles used in the system of FIG. 
1; 



EP 1 189 405 A1 



15 



20 



25 



30 



35 



AO 



45 



50 



2 



3 



EP 1 189 405 A1 



4 



FIG. 5 shows a block-schematic diagram illustrating 
major steps in a terminal-originated call in the sys- 
tem of FIG. 1; 

FIG. 6 shows a block-schematic diagram illustrating 
session set-up procedure in the system of FIG. 1; 

FIG. 7 shows a block-schematic diagram illustrating 
cellular connection set-up procedure in the system 
of FIG. 1; 

FIG. 8 shows a block-schematic diagram illustrating 
broadcast connection set-up procedure in the sys- 
tem of FIG. 1; 

FIG. 9 shows a block-schematic diagram illustrating 
transmission procedure in the system of FIG. 1 ; and 

FIG. 10 shows a block-schematic diagram illustrat- 
ing an example of mobility management procedure 
in the system of FIG. 1 . 

Description of Preferred Embodiment(s) 

[0015] In a preferred embodiment of the present in- 
vention, the architecture of a composite radio system is 
based on a special server, hereafter termed a Compos- 
ite Access Server (CAS), acting as a gateway and a 
proxy. Such an architecture is shown in FIG. 1. 

1 Composite Radio System Architecture 

[0016] In the composite radio system 100 of FIG. 1, 
one or more Composite Access Server(s) (CAS) 1 1 0 are 
provided at the border between two domains: 

On one side of the CAS(s) 110 is the Internet world. 
In this domain 120, application servers 130 and 
WEB sites (not shown) stand. Usually, the content 
servers do not know the details of transmission 
means used by mobile terminals 140. The network 
layer in this domain is best demand driven. 
On another side of the CAS(s) 110 is the wireless 
domain 150. It is composed of sub-networks, each 
one being actually the core network of an operator 
operating a specific technology, e.g., a broadcast 
(DVB-T) network 160, a cellular (e.g., GPRS or 
UMTS) network 170, and a WLAN (e.g., Hiperlan 1) 
network 180. The network between the CAS and 
the core networks is packet-switch based, since this 
should offer better quality of service (QoS) charac- 
teristics than the Internet. On this network, the core 
networks 160, 170 and 180 are accessed via oper- 
ator-specific gateways. If a core network operates 
multiple technologies, this is transparent to the 
CAS. 

[0017] On the Internet side, the CAS 110 negotiates 



on behalf of the user the service profile the user wants 
to connect. The main goal with this approach is to limit 
the communications on the wireless side. One require- 
ment is that the CAS holds sufficient information about 
5 the user profile and preferences. 

[0018] The CAS 110 continuously evaluates the us- 
age of the wireless spectrum occupied by the mobile us- 
ers and optimizes it on a global basis. The actions the 
CAS can perform for this purpose (with support of the 
application provider) are, among others, splitting of data 
streams over multiple^technologies based on QoS and 
relevance parameters, and content re-negotiation. 
[0019] The CAS 110 can also act as a service proxy 
and may provide added-value services such as map- 
ping of multicast transmission on broadcast spectrum, 
roaming or handover between technologies, content 
transcoding, QoS filtering, and re-assignment of tech- 
nologies on the available spectrum. 
[0020] In order to perform the functionalities men- 
tioned above, two signaling links are required: 

between the CAS 110 and the application servers 
130, and 

between the CAS 1 1 0 and the mobile terminal 1 40, 

[0021] One more signaling link can be included if a 
cooperation mechanism exists between the CAS 110 
and the radio access network gateways 165, 175 and 
185. 

[0022] The signaling links are derived from principles 
described in the publications 'Generic Signaling Proto- 
col: Architecture, Model, and Services', P. Miller and P. 
[0023] Turcu, IEEE Transactions on Communica- 
tions, Vol. 40, No 5, May 1992, and 'Generic Signaling 
Protocol: Switching, Networking, and Interworking', P. 
Miller and P. Turcu, IEEE Transactions on Communica- 
tions, Vol. 40, No 5, May 1992 (both of which publica- 
tions are hereby incorporated herein by reference). 
Hereafter, these signaling links will be referred to com- 
monly referred to as Signaling Link for Access Entities 
(SP/A). 

[0024] The CAS 110 provides call control functionality 
and performs intelligent routing of flows. From a wider 
system standpoint, the CAS 110 controls the traffic over 
a limited geographical area, where multiple technolo- 
gies are available. To control larger areas, a network of 
CASs is implemented for instance as a "meta-core net- 
work" as suggested in FIG. 2. 

[0025] As can be seen in FIG. 2, a plurality of CASs 
110 communicate (via an inter-CAS network 115) with 
the Internet domain 120 (including application servers 
130). The CASs 110 respectively provide different geo- 
graphical coverage areas 210 (only one of which is 
shown) in which wireless services such as DVB, UMTS 
and WLAN are provided. It will be appreciated that a 
communication between a terminal (not shown in FIG. 
2) and an application server 130 server results in the 
subset shown in FIG. 1 . 
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2 Addressing principles and protocol stacks 

[0026] All blocks in the architecture are interconnect- 
ed using an IP protocol. As will be explained in further 
detail below, in order to simplify addressing of the van- 5 
ous blocks, as well as simplifying the CAS functionalities 
while matching the architecture requirements, an appro- 
priate addressing scheme is set up. Further, protocol 
stacks are arranged in the different entities. 

2. 1 Addressing 

[0027] Referring now also to FIG. 3, the addressing 
scheme is based on that of the publication 'Flexible Net- 
work Support for Mobile Hosts', X. Zhao, C. Castellucia 
and M. Baker, Mobile Networks and Applications 1999 
(which publication is hereby incorporated herein by ref- 
erence), which makes it possible to reach a user using 
simultaneously multiple links, in an IP context. The ad- 
dressing scheme must take into account the facts that: 

IP protocol principles (e.g., that one IP address 
identifies a network access point) must be respect- 
ed; 

the server does not necessarily know the terminal 
interface IP address for each radio technology at 
connection set-up; 

the IP address/port is only a temporary identification 
of the radio technology(ies) to reach the user from 
the network; and 

the client-server traffic will be strongly asymmetri- 
cal, server-client being the dominant direction. 

[0028] In the server domain, it is necessary to identify 
the flows addressed to the client. Two flows are different 
when they show different characteristics such as the re- 
quired QoS or the priority, and when only the application 
server is able to build the data stream accordingly. As a 
consequence, each flow can be mapped on a different 
transport protocol, and different application flows can al- 
so be multiplexed at the transport layer. 
[0029] As a result, a flow or a set of flows will be iden- 
tified at least by the set <source:port, destinations The 
source address is the application server address. The 
port is associated with the source address and differen- 
tiates transport streams characteristics. The destination 
address is the one from the user, registered at the CAS. 
[0030] On the CAS-client side, a mapping of a trans- 
port stream into a selected radio transmission will be 
identified by the set <source, destination> IP addresses. 
The source IP address is the CAS IP address while the 
destination address is the terminal address in a specific 
radio technology. The packets are tunnelled from the 
CAS to the user terminal radio interface. The destination 
address (external address of the IP/IP tunnel) is the tem- 
porary address given by the radio access network to the 
radio interface for this terminal interface to be accessed 
through an IP network. 



[0031] One function of the CAS is then to encapsulate 
transport flows in the Internet side, for delivery in the 
wireless domain side, and in reverse to de-capsulate 
packets from the user to route them to the server, as 
illustrated in FIG. 3. Since the addressing principles are 
similar to mobile IP, the CAS can be identified to the 
home agent while the terminal would be foreign agents 
to be addressed simultaneously. 
[0032] The addressing principles used in the compos- 
ite radio systems architecture of FIG. 1 and 2 are illus- 
trated in FIG. 3. As can be seen from FIG. 3, the CAS 
110 dynamically adapts the binding table 310 for each 
user, based on the traffic characteristics, the transport 
stream characteristics, the QoS reqired by the streams 
versus the one proposed on each link, on a per-user ba- 
sis, and at system level. The traffic characteristics are 
either measured or explicitly carried with the SP/A sig- 
naling links mentioned in earlier. Interworking with con- 
tent servers not supporting SP/A is possible, but the 
CAS must rely on its traffic characteristics measurement 
means to optimize flow handling. 
[0033] It is to be noted that in the example shown in 
FIG. 3, in case of an assured transport protocol such as 
TCP while using a unidirectional transmission technol- 
ogy (gateway 165), the CAS may have to provide pro- 
tocol translation means in order to emulate an end-to- 
end (TCP) connection. If the CAS is to act as a service 
proxy (e.g., for content filtering/transcoding), then the 
binding table would need to be more complex. It would 
need in particular to bind content objects to destination 
addresses, rather than just source addresses/ports. 
[0034] On the Internet side, it is preferred to distin- 
guish transport flows per port number instead of ad- 
dress, in order to facilitate priority handling of flows in 
case stateless QoS protocols (such as DiffServ) are 
used. 

[0035] On the wireless side, tunneling is applied to the 
original packets, in order to keep end-to-end syntax on 
the received packets. Reverse tunneling is a desirable 
option when bi-directional radio technology is in use. It 
can serve in particular to transport TCP acknowledge- 
ments, or RTCP reports. A tunneling approach enables 
the user to be accessed via any radio technology or sub- 
network, provided that the CAS is informed of possible 
networks. 

[0036] On mobile IP enabled networks, and in case of 
availability of static addresses for users in a specific ra- 
dio technology, packets originating from the CAS may 
experiment a second tunneling between the home radio 
access network gateway, and the foreign one. In such 
cases, some form of optimization (e.g., header com- 
pression) may be needed. 

[0037] In the context of a network of CASs, the con- 
cept of home CAS and foreign CAS can be introduced. 
Then, mobile IP principles may be used for mobility 
management. 
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2.2 Protocol stacks 

[0038] The general principle used in arranging proto- 
col stacks is to separate the control plane from the user 
plane. Thus, flows from each plane can be independ- 5 
ently mapped on the most appropriate transport proto- 
col, and transmission technology. 
[0039] The control plane actually addresses how the 
SP/A protocol for call control is distributed and commu- 
nications are established. The SP/A is distributed over 
the client, the server, and the CAS. Because of its vital 
importance in the system operations, it preferably uses 
the most reliable link to reach the terminal (which would 
be the cellular air interface in most cases). 

3 Call model principles 

[0040] The composite radio system under considera- 
tion involves at least five physical entities, and distinc- 
tion is made between the application and the session 
layers. The physical entities are the terminal, the com- 
posite access server, the application server, the broad- 
cast technology gateway, and the cellular (bi-direction- 
al) technology gateway. 

[0041] Terminal originated call set up is described be- 
low. Similar principles can be applied for terminal termi- 
nated calls. 

3. 1 Modeling principles 

[0042] Referring now also to FIG. 4, the call model 
used is based on a client-server model, in which the ter- 
minal runs the client side of the user application and the 
application server runs the server side of the user appli- 
cation. The composite access server is in principle only 
visible at the session layer. As a result, the session layer 
is distributed over three entities. The session layer soft- 
ware can be seen as a middleware with the function of 
running the services supported by the functions imple- 
mented in the composite access server. 
[0043] The user application is connected to the ses- 
sion layer through an interface called the Composite Ra- 
dio System Application Interface (CRS-Al). The primi- 
tives exchanged on this interface can be considered as 
the Application Programming Interface (API) needed to 
support the CRS concept. 

[0044] The terminal and the composite access server 
communicate via the CAS-Terminal Interface (CTI). 
Messages exchanged on this interface are part of the 
session control protocol. 

[0045] The application server and the composite ac- 
cess server communicate via the CAS-Server Interface 
(CSI). Messages exchanged on this interface are also 
part of the session control protocol. 
[0046] A transaction can be initiated either by the cli- 
ent or the server using a request primitive on the CRSI 
primitive. When the client starts the transaction, it trans- 
mits command messages at the session level, to trie 



peer entity. A session level reply message is expected. 
When the server starts the transaction, it transmits no- 
tification messages at the session level, to the peer en- 
tity. As in the previous case, session level reply mes- 
sages are expected. 

[0047] The underlying transport protocol is assumed 
to provide assured transmission of the messages. In an 
IP context, TCP would provide such service. 

3.2 Call model 

[0048] The call model described below is given for 
clarification on how the different entities in the compos- 
ite radio system exchange information at the session 
level. It is to be noted that call model described is simply 
one possible implementation, not unique, and that other 
implementations may alternatively be used.. 
[0049] Terminal originated call set up is organized in 
three procedures: session set-up, radio connection set- 
up (different for cellular and broadcast), and transmis- 
sion. Each procedure is initiated by a request/indication 
issued from/to the application layer to/from the session 
layer. The session layer 410 is distributed between the 
terminal, the composite access server, and the applica- 
tion server. A link keeping procedure is also used in or- 
der to highlight that the link quality may be adapted to 
fit the application requirements as well as the transport 
time varying conditions. 

[0050] Figure 5 depicts a generic message sequence 
chart (indicating particularly the entities involved in each 
procedure of the call set-up) and shows the major steps 
in a terminal originated call. 

[0051] The primitives in the CRSI interface consist of: 

►> 

service addition (equivalent to an application ses- 
sion), 

• channel creation/addition (preferably one per QoS 
class), 

application command (e.g., send data), and 

• channel attribute modification. 

[0052] In the example above, after session set-up 
(step 510), the terminal is recommended to open two 
channels with different QoS attributes. The session lay- 
er finds out (again, based on CAS recommendation) that 
it is better to open one transport link per application 
channel. In other circumstances, the session layer could 
have mapped both application channels on the same 
transport link. As shown in FIG. 5, after session set-up 
(step 510), the following steps are performed: cellular 
connection set-up (step 520); broadcast connection set- 
up (step 530); transmission (step 540); and link keeping 
(step 550). 

3.2.1 Session set-up 

[0053] FIG. 6 shows the session set-up step 510 in 
more detail. The session set-up procedure consists of 
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the establishment of a signaling link between the termi- 
nal 140, the composite access server 110 and the ap- 
plication server 130. The terminal selects the most reli- 
able radio link. During this procedure, the composite ac- 
cess server derives the most appropriate configuration 
for (simultaneous) usage of multiple radio access net- 
works. The assumption is that the composite access 
server knows sufficiently about the terminal environ- 
ment, terminal capabilities and user preferences, as welt 
as about the application scalability properties. The com- 
posite access server recommends to the mobile termi- 
nal the preferred setup for the application (number of 
application channels, bit rates, delay, etc.), and for the 
session layer (number of radio links; QoS to provision, 
etc.). 

[0054] It is assumed that the gateways from the radio 
access networks may be able to provide information 
about achievable capacity at the terminal location, prior 
to actual reservation. Instead, a default value may be 
provided. 

3.2.2 Cellular connection set-up 

[0055] FIG. 7 shows the cellular connection set-up 
step 520 in more detail. In cellular networks like GPRS, 
the terminal is asked to initiate the packet data context, 
even for incoming calls, in order to achieve the appro- 
priate bi-directional QoS provision from the terminal to 
the cellular gateway. This is why the application primitive 
CRSI-AddChannelReq triggers connection to cellular. 
The terminal initiates the connection in the cellular tech- 
nology based on the QoS parameters provided by the 
composite access server. Once established, the termi- 
nal reports back to the composite access server the pre- 
cise QoS parameters granted. Then, the composite ac- 
cess server establishes the connection with the appli- 
cation server. A confirmation is sent to the terminal once 
the application confirms the link characteristics. 
[0056] When the terminal asks for a context activa- 
tion, it is assumed that it is already attached to the pack- 
et data service. If this is not the case, then a preliminary 
packet data service attach procedure would be required. 
The context activation will be required in most cases in 
order to adapt the QoS parameters. 

3.2.3 Broadcast connection set-up 

[0057] FIG. 8 shows the broadcast connection set-up 
step 530 in more detail. In the broadcast connection set- 
up procedure, the composite access server initiates the 
connection in the broadcast technology, after request 
from the terminal. Once established, the composite ac- 
cess server establishes connection with the application 
server. A confirmation is sent to the terminal once the 
application confirmed the link characteristics. 



3.2.4 Transmission 

[0058] FIG. 9 shows the transmission step 540 in 
more detail. In the transmission procedure, once the 
5 transport channels are established according to the 
composite access server recommendations, the termi- 
nal initiates the interaction with the application server, 
by sending a specific command CRSAI-UserComman- 
dReq. 

10 [0059] It may be noted that the session layer in the 
terminal and the application server may provide seg- 
mentation/reassembly functionality appended with syn- 
chronization information. 

15 3.2.5 Link keeping procedure 

[0060] Based on network management alarms, 
changes in the terminal environment, changes in the ap- 
plication requirements, etc., the composite access serv- 
20 er has the role of adapting the transmission resources. 
The example in FIG. 5 (step 550) shows the case when 
only link properties need to be changed. Another exam- 
ple would be when links need to be added or removed 
in order to benefit or take into account the radio envi- 
25 ronment. 

[0061] The link keeping procedure basically consists 
in changing the call characteristics in such a way that 
new system requirements are met. It is expected that 
such procedure will actually have an impact on many 
30 calls. The call characteristics change can be explicit if 
messages are issued to provide new parameters, or im- 
plicit in particular when the number and type of radio 
links need only to change from a QoS point of view. In 
this latest case, approaches involving packet marking 
35 should be considered, in order to make faster link char- 
acteristics changes. 

4 Mobility management principles 

^0 [0062] When a mobile terminal is roaming, the home 
CAS may not be the best located to manage the terminal 
call. Other CAS may be best located in the network, 
hence minimizing routing. 

[0063] Referring now also to FIG. 10, based on the 
45 temporary address the terminal is using to set up a call, 
the home CAS 110.1 can determine whether it is the 
best suited to serve this call, or if another CAS can per- 
form better. In the second case, a mobility management 
procedure is introduced, in order to transfer the context 
50 of the user (using the terminal) to the best CAS. This 
procedure is illustrated in FIG. 10. 
[0064] The mobile terminal issues session set up re- 
quest to the home CAS 110.1. The home CAS deter- 
mines whether it is best suited to serve the request, 
55 based on for instance on the IP addresses the terminal 
exhibits. If a visitor CAS 110.2 is required, the home 
CAS contacts it to check whether it is available, and 
transfers to it the user context and profile. The home 
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CAS 110.1 informs the terminal about the new CAS to 
use. The next user requests are directly transmitted to 
the visitor CAS 110.2. 

[0065] Other technologies such as mobile IP could be 
used for mobility management purposes but would re- 
quire additional capabilities in order to support context 
transfer from one node to another. 
[0066] The mobility management procedure de- 
scribed earlier is triggered at connection set-up. How- 
ever, network management procedures could force this 
procedure as well in case of, for example, CAS failure. 

5 Resource management principles 

[0067] Network management procedures are internal 
to the CAS 110, and network of CASs. User terminals 
indirectly contribute to efficient resource management 
because they explicitly express their QoS needs has 
well as terminal capabilities. The resource management 
actions, when applicable to the terminal users (radio 
technology handover, transceiver technology change, 
application channels switched on/off, etc), are commu- 
nicated with the user call control procedures, through 
the choice of parameters that the CAS gives. 
[0068] In summary, it will be understood that the 
present invention makes use of a new entity called the 
composite access server (CAS), which is an intermedi- 
ary node (gateway and router) between a mobile termi- 
nal (client) and an application server. As exemplified 
above, its roles are to: 

dynamically tailor the service requested by a user, 
on behalf of the user, based on terminal capabilities 
and accessible radio and/or network resources; 
optimize the usage of radio and network resources 
at a system level, based on service requests and 
available radio technologies; 

• ensure service continuity across multiple radio 
technologies; and 

• enables parallel connections over multiple radio 
networks. 

[0069] The CAS may be part of a network of CASs, 
each of which is attached to a respective geographical 
area. Thus, a user is attached to the CAS associated 
with the geographical area where the terminal is located. 
IT is to be noted that a given geographical area can be 
covered by more than one radio technology. 
[0070] In order for the CAS to optimally tailor the ap- 
plication delivery, two types of signalling links are de- 
fined: 

between the CAS and the terminal: the terminal 
communicates information about its radio environ- 
ment (available technologies) and terminal capabil- 
ities; and 

between the CAS and the application server: the 
CAS tailors, on behalf of the user, the service in or- 



der to best match the terminal capabilities and avail- 
able radio resources and technologies 

[0071] Optionally, the CAS can have a third signalling 
5 link between the CAS and a control entity of each radio 
core network in order for the CAS to evaluate (with con- 
trol entity collaboration) the available capacity at termi- 
nal location for each technology; thus, the CAS can de- 
termine how to map data streams on radio technologies. 
[0072] With the described arrangement, the CAS is 
able to perform radio resource optimization with one of 
the following means: 

the CAS has the possibility of splitting, or indicating 
to the application server to split, the contents into 
multiple streams, in order for the CAS to be able to 
map each stream on the radio technologies availa- 
ble at the terminal side; 

the CAS can perform traffic shaping and/or service 
translation in order to match the service data stream 
with the available resources; and 
the CAS is able to collect statistics about the service 
demand on the area under control, and dynamically 
adapt the set of radio technologies used in the area 
by indicating reconfigurability of base stations - this 
can consist in the CAS dynamically assigning spec- 
trum to radio systems according to the nature of 
services required in specific geographical area 
(broadcast versus unicast services, symmetrical 
versus asymmetrical services, etc.). 

[0073] It will be appreciated that the present invention 
provides a call control protocol that (i) is independent of 
underlying transport protocols and networks, and (ii) in- 
volves the application server 1 30, the CAS 1 1 0, the user 
terminal 140 and radio networks gateways in order to 
enable flexible spectrum assignment and base station 
reconfigurability. 

[0074] It will be further appreciated that the present 
invention provides an Application Programming Inter- 
face for the user terminal that (i) enables the creation of 
application contexts, and (ii) implemented and executed 
in a distributed manner between the client (user terminal 
140), server (application server 130) and the access 
server (CAS 1 1 0). It will be understood that the Applica- 
tion Programming Interface may not need to be support- 
ed by the content server if the CAS implements appli- 
cation proxys. 

[0075] The present invention finds particular applica- 
tion in wireless communication systems such as the 
UMTS or GPRS systems. However, the inventive con- 
cepts contained herein are equally applicable to alter- 
native fixed and wireless communications systems. 
Whilst the specific, and preferred, implementations of 
the present invention are described above, it is clear that 
variations and modifications of such inventive concepts 
could be readily applied by one skilled in the art. 
[0076] Thus, a network system, method for transfer of 
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data and server for use therein have been provided that 
alleviate some of the above mentioned disadvantages. 



Claims 

1. A network system including a wired network (120) 
and a wireless network (160, 170, 180), the system 
comprising: 

a data server (130) and a terminal (140) ar- 
ranged for transfer of data therebetween 
across wired and wireless networks upon re- 
quest by a user; and 

an access server (110) functionally connected 
between the data server and the terminal for 
dynamically facilitating transfer of data there- 
between, the access server comprising means 
for holding information on features of the termi- 
nal and means for holding information on radio 
resources available in the wireless network and 
for controlling transfer of data between the data 
server and the terminal in dependence on the 
held information. 

2. The network system according to claim 1 wherein 
the access server (110) comprises at least one of 
A-F: 

A means for controlling routing packet informa- 
tion between the access terminal and the ter- 
minal; 

B call control means; 

C user management means for controlling trans- 
fer of data dependent on charging and billing 
information; 

D security means for controlling transfer of data 
dependent on security user and/or data secu- 
rity levels; 

E gateway means for translation of session level 

protocols; and 
F proxy means for transferring data as a proxy. 



10 



15 



20 



25 



30 



35 



40 



G means for controlling routing packet informa- 
tion between the access terminal and the ter- 
minal; 

H call control means; 

I user management means for controlling trans- 
fer of data dependent on charging and billing 
information; 

J security means for controlling transfer of data 
dependent on security user and/or data secu- 
rity levels; 

K gateway means for translation of session level 

protocols; and 
L proxy means for transferring data as a proxy. 

A method for transfer of data between a data server 
(130) and a terminal (140) across a wired network 
(120) and a wireless network (160, 170, 180), the 
method comprising: 

providing an access server (110) functionally 
connected between the data server and the ter- 
minal for dynamically facilitating transfer of da- 
ta therebetween, the access server comprising 
means for holding information on features of 
the terminal and means for holding information 
on radio resources available in the wireless net- 
work and for controlling transfer of data be- 
tween the data server and the terminal in de- 
pendence on the held information. 

The method according to claim 3 further compris- 
ing, in the access server (110), at least one of M-R: 



M 

N 
O 



Q 
R 



controlling routing of packet information be- 
tween the access terminal and the terminal; 
call control; 

controlling transfer of data dependent on 
charging and billing information; 
controlling transfer of data dependent on se- 
curity user and/or data security levels; 
translating session level protocols; and 
transferring data as a proxy. 



3. An access server (110) for use in a network system 
including a wired network (120) and a wireless net- 45 
work (160, 170, 180), the access server being ar- 
ranged for functional connection between a data 
server (130) and a terminal (140) for dynamically 
facilitating transfer of data therebetween, the ac- 
cess server comprising means for holding informa- 50 
tion on features of the terminal and means for hold- 
ing information on radio resources available in the 
wireless network and for controlling transfer of data 
between the data server and the terminal in de- 
pendence on the held information. 55 

4. The access server (110) according to claim 3 further 
comprising at least one of G-L: 
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